Preserving Co- Location Privacy in Geo-Social Networks 
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Abstract 

The number of people on social networks has grown 
exponentially. Users share very large volumes of per- 
sonal informations and content every days. This 
content could be tagged with geo-spatial and tem- 
poral coordinates that may be considered sensitive 
for some users. While there is clearly a demand 
for users to share this information with each other, 
there is also substantial demand for greater control 
over the conditions under which their information is 
shared. Content published in a geo-aware social net- 
works (GeoSN) often involves multiple users and it is 
often accessible to multiple users, without the pub- 
lisher being aware of the privacy preferences of those 
users. This makes difficult for GeoSN users to con- 
trol which information about them is available and 
to whom it is available. Thus, the lack of means to 
protect users privacy scares people bothered about 
privacy issues. This paper addresses a particular pri- 
vacy threats that occur in GeoSNs: the Co-location 
privacy threat. It concerns the availability of infor- 
mation about the presence of multiple users in a same 
locations at given times, against their will. The chal- 
lenge addressed is that of supporting privacy while 
still enabling useful services. 

1 Introduction 

The great availability of social network services and 
mobile devices with internet connectivity and in- 
tegrated GPS enable Geo-aware Social Networks 



(GeoSNs). Several different existing GeoSNs allow 
users to share their location (frequently, their exact 
location on a map) and other types of information, 
but have extremely limited privacy settings. Typi- 
cally, they only allow users to specify location infor- 
mations with higher granularity (for example, a city), 
or a list of individuals with whom they would be will- 
ing to share their locations at any time [ID]. While 
there is clearly a demand for users to share this in- 
formation with each other, there is also substantial 
demand for greater control over the conditions under 
which their information is shared, and a number of 
recent papers demonstrate that individuals are con- 
cerned about privacy in this domain pQ E] • 

Thus, privacy in social networks is a hot topic, and 
reports indicate that an increasing number of users 
are concerned about privacy issue, enough to leave 
GeoSNs [3 . In GeoSNs, exact locations of users are 
published and can be red by multiple users. Thus, 
potentially untrusted entities may exploit these to 
infer sensitive information about the users and make 
some unwanted focused actions. Recent studies has 
been performed on different aspects of user privacy 
that are potentially at risk [21 [7] . These works exam- 
ine specific privacy threats and try to give possible 
solutions. In particular the Location Privacy, the Ab- 
sence Privacy and the Co-Location Privacy threats 
are araised. While the first two problems are widely 
discussed in [2j , the Co-Location Privacy still remains 
unexplored, as far as we know. 

In most GeoSNs, an adversary might be able to ob- 
serve the presence of multiple users in the same place 



and some users consider such co-location to be sen- 
sitive. Thus, disclosing this information to an adver- 
sary constitutes a co-location privacy violation. None 
of the currently known GeoSNs supports co-location 
privacy [7] , and specifying privacy preferences related 
to co-location can be challenging. 

The objective of this paper is to explore this prob- 
lem and provide preliminary techniques that enable 
users to specify their privacy preferences and then en- 
force these preferences. Our approach is based on the 
studies performed in [2]. We apply meta-data gener- 
alization in order to make not possible for any set 
of resources violate any users preference, also taking 
into account constraints on the maximum velocity of 
user movement. The proposed technique enforce the 
co-location privacy by computing appropriate spatial 
enlargement (where possible) in resource publication. 

Although privacy has been studied extensively in 
location-based services and social networks [HI HI El 
ITTj . we are not aware of any studies that consider 
co-location privacy in the GeoSN setting. 

Finally, some existing GeoSN services offer some 
form of control of the geo-tags of resources, e.g., by 
enabling tags at coarse granularities such as the city 
level (e.g., Google Latitude), but much finer controls 
are necessary to avoid the privacy threats considered 
in this paper. The contributions of the paper are the 
following: 

• Formalization of co-location privacy threat in 
GeoSN and adversary attacks. 

• Proposals of means of expressing privacy prefer- 
ences. 

• A privacy preserving technique that guarantees 
the enforcement of user preferences. 

The rest of the paper is organized as follows. Sec- 
tion [5] formally characterizes the co-location privacy 
threat in GeoSNs, the adversary model and how users 
can specify their privacy preferences; Section [3] de- 
scribes the algorithm of the proposed GeoSN privacy 
preservation technique; Section [4] discuss the applica- 
bility of our technique to existing GeoSNs; Section [5] 
reports our conclusion. 



2 Problem Formalization 

In this section, we formally describe the assumed 
GeoSN service resources and the privacy threats we 
address. Then we define how users can express their 
privacy preferences, the adversary model, and suffi- 
cient conditions for satisfying a user's privacy prefer- 
ences. 

2.1 GeoSN Resources 

A GeoSN service allows its users to publish a resource 
(e.g., a picture, a text message, a check-in) tagged 
with the current location and time, as well as a set 
of users related to the resource. A resource is ei- 
ther automatically tagged (e.g. an integrated GPS 
can provide location and time), or manually tagged. 
Since resources and their tags become available to 
other users as well as to service providers, we are 
concerned with the privacy violations that the publi- 
cation can lead to. Formally, a resource r is a tuple: 



(U,T,S,C) 



(1) 



where the elements are meta-data tags, with r.U 
being a set of identifiers of users, r.S being a spa- 
tial tag, r.T being a temporal tag and r.C being the 
resource itself. In the following, when referring to a 
resource r, we assume that all the users in r.U are in 
the location r.S at the time r.T. We denote the user 
that makes r as oumer{r). Note that: 



r.U 3 owner (r) A 
Vit £ r.U \ {owner(r)}, j ' riend{owner{r) , u) 



(2) 



where friend is a "friendship" relation between 
users. Location of a resource could be recorded at 
the finest available resolution (a point in the appro- 
priate domain) or with higher granularity, that is a 
larger area. Time of a resource is a timestamp with 
date and time. In this paper we refer to a real time 
publication model. This means that each resources 
has an accurate timestamp and users can't publish 
resources referring to the past. This model may in- 
clude for example proximity services, micro-blogging, 
and social navigation services. We denote the set of 



resources of the GeoSN as R C 1Z (the resources do- 
main) . 

In accordance to a consolidated idea [2], we based 
our approach on the generalization of the resources 
before publication. In particular, when we identify a 
resource r that violate the privacy of a user (or a set 
of users) we apply a function g that takes a resource 
r and generate a resource r' that doesn't violate the 
privacy of any users. Formally, a generalization func- 
tion is g : 1Z — > TZ: 



ext(r.S, r'.T - r.T) 




Figure 1: Consistency of resources. 



g(r = (U,T,S,C)) = (/ = (U',T,S',C)) (3) 

where U' C [7 and S C. S'. The function <j>(r) takes 
into account the privacy preferences expressed by the 
users and try to make a new resource that does not 
violate these preferences. 

In the following we recall two basic concepts (first 
introduced in [2]) that will be used in the next sec- 
tions. A resource r is reachable from another re- 
source r' if each spacial point in r are reachable 
from some spacial points in r', in the time interval 
\r.T — r' .T\ moving with an acceptable speed. For- 
mally: 

Definition 1 (Reachability). Given a velocity V max 
and two resources r, r' , we say that r is reachable 
from r' if: 



Vs e r.S, 3s' € r'.S 



d(s,s') 

\r.T-r'.T\ 



<V„. 



(4) 



where d(s, s ') compute the distance between the two 
spacial points and V max is the maximum acceptable 
medium speed for a user. 

Two resources are independent if they have not 
users in common or if their spatial distance is small 
when compared with the temporal distance. For- 
mally: 

Definition 2 (Independence). Given two resources 
(r, r') € R x R, we say that r and r' are independent 
(and we denote it with r _L r') if: 



r.UHr'.U = V 
(r reachable from r A r reachable from r) 



Independence of resources ensures that each re- 
source doesn't restrict the informations given by any 
other resources. This property allows to avoid a par- 
ticular attack from the adversary. For example, sup- 
pose that in Fig. [I] are represented the spatial infor- 
mations of two consecutive resources that involve the 
user u. The ext function computes the area in which 
any user located in r.S at the time r.T, can be located 
at the time r' .T (considering the maximum speed of 
users). Thus, the adversary can infer that only a sub- 
set of r' .S is a possible location for u. we will clarify 
the need of independence of resources in the section 



(5) 



2.2 Co-Location Privacy Threat 

We consider geographical location and temporal lo- 
cation as sensitive information that sometimes users 
want to maintain private. When an adversary can 
associates user's identity with these kind of informa- 
tions without the user's consensus, a privacy violation 
has occurred. This paper focuses on the Co-Location 
privacy problem. In this section we give a descrip- 
tion of this privacy threat and we give a description 
of how users could describe their privacy preferences 
in order to protect themselves from this problem. 

A typical Co-Location privacy threat example is a 
user that doesn't want to let people know that (s)he 
is located in a specific place at a specific time with 
her/his secret lover. For instance, imagine that Alice 
and Bob are secret lovers and they having a drink to- 
gether in a pub. They don't want to let other people 
know their secret meeting, but Bob sees his friend 
Charlie that updates his status, writing "just met 



Bob at a pub!" and tagging the post with 12:02 p.m., 
24 West 35th Street. A bit later Alice sees her friend 
Juliette that updates her status, writing "just met Al- 
ice at a pub!" and tagging the post with 12:10 p.m., 
24 West 35th Street. A user with access to both posts 
(e.g., a friend of Bob and Alice) can infer that Alice 
and Bob are co-located without their consensus. 

The disclosure of a co-location can occur in two 
different ways: a direct way and an indirect way. 
The direct disclosure occur when a single resource r 
co-locates a set of users U that don't want to be co- 
located. The indirect disclosure occur when a pair of 
resource r, r' co-locate two different subset of U in a 
"small" area and with "small" time difference (this is 
the case presented in the above example). We discuss 
what we mean with "small" in section 12.41 

This privacy threat can be addressed by offering 
the users means of controlling the location informa- 
tion to be disclosed. This means include different 
kinds of privacy preferences that users can express. 
We model the preferences for avoid co-location pri- 
vacy threat for a user u as a tuple tp: 



with Bob in less than 50 meters and during the 
evenings, unless Bob's wife (Mary) is there as well." . 
This privacy preference can be represented by a re- 
curring (infinite) set of tp tuple of the type: 
( Bob, Mary, 11th July '11 (19:00 p.m.) - 11th July 
'11 (23:00 p.m.), 50 m. ) 

( Bob, Mary, 12th July '11 (19:00 p.m.) - 12th July 
'11 (23:00 p.m.), 50 m. ) 

( Bob, Mary, 13th July '11 (19:00 p.m.) - 13th July 
'11 (23:00 p.m.), 50 m. ) 
and so on... 

starting from the day in which Alice has set this 
preference. We indicate the set of the privacy settings 
of the user u with $(u). 

Intuitively, when a user want to make a resource r 
that violates this preference we apply a generalization 
function g to r that obfuscate the meta-data of r, 
in order to preserve the privacy of Alice and Bob. 
Obfuscation in our case means the enlargement of the 
area expressed by r.S or the removal of some user in 
r.U, so that an adversary is not able to infer exact 
informations about the victims. 



(E,A,T,D) 



(6) 



where ip.E and tp.A are sets of users, tp.T is a time 
interval and tp.D is a spatial distance. In particular, 

• tp.E is called Excluding Set and represent the 
set of users with whom u doesn't want to be co- 
located. 

• tp.A is called Adversary Set. Co-location of u 
with any users in ip.E is allowed if the co-location 
includes any users in ip.A as well (we'll explain 
better this concept in the next section). 

• tp.T is the time interval in which u doesn't 
want to be co-located. tp.T have a starting 
time (t s tart) and an ending time (t en d). tp.T is 
bounded (t end - t start < T max ). 

• tp.D is the minimum distance within u doesn't 
want to be co-located. tp.D is bounded (tp.D < 

Umax ) • 

For instance, a possible co-location privacy prefer- 
ence for Alice could be "Don't reveal my co-location 



2.3 Adversary Model 

The adversary is a user of the GeoSN that want to 
use published resources to infer sensitive informations 
about other users (victims). We assume that the ad- 
versary has access to all the resources published by 
all the users. This conservative approach is not a re- 
alistic context but it has two important effects: (a) 
if the co-location privacy is preserved against an ad- 
versary that has access to all the resources of the 
GeoSN, it is also preserved against an adversary that 
has a restricted access to the resources; (b) this ap- 
proach permits to avoid any chance by an adversary 
to exploit future friendship relations (or friendship re- 
lations not in common with the victims) in order to 
gain access to additional sensitive informations about 
users. We also assume that the adversary knows the 
generalization technique used to generalize resources 
before publication, but (s)he doesn't know the pri- 
vacy preferences of other users because these infor- 
mations are only available if (s)he has access to other 
accounts (and we assume that (s)he doesn't have it). 
When a resource r £ R states that a user u is 



located in the area r.S at the time r.T, the adversary 
can assume a uniform probability distribution of user 
location, that is: 



Vs£ r.S, P{loc{u) = s) 



P 



(7) 



where loc(u) indicates the exact spatial location 
of the user u. Instead Vi 7^ r.T, the adversary can 
assume that u can be located in a larger area: 



(8) 



P(loc{u) = s) > 0, if s G ext(r.S, \t - r.T\) 
P(loc(u) = s) = 0, if a i ext(r.S, \t - r.T\) 



with ext being the function defined in section [2. 1| 
This means that we consider not null the probability 
that u is located in a larger area if u, moving with an 
acceptable medium speed, can be in this area after 
the time interval \t — r.T\. 

Concerning the co-location privacy of a user u, we 
consider it as preserved if V <p G <&(u), the adversary 
doesn't have any chance to consider null the proba- 
bility that u is at least tp.D far from any users in ip.E 
in the temporal interval ip.T. 

Definition 3 (Co-Location Privacy preservation of 
a user u). The Co-Location Privacy of ' u is preserved 
*/■■ 



\/p G $(u), V t G ip.T, V eeip.E 
P{d(u,e) > p.D) > 



(9) 



and this holds as long as doesn't exists any set of 
resources that makes null this probability. 

Definition 4 (Co-Location Privacy preservation). A 
GeoSN preserve the Co-Location Privacy if: Vtt, the 
Co-Location Privacy of u is preserved. 

However, even any set of resources in R doesn't 
violate the co-location privacy of a user it, a sly ad- 
versary (that know how the principle of the gener- 
alization technique works) could try to make some 
fake resource in order to infer the privacy preference 
of u. For instance, imagine that Mary (the jealous 
wife of Bob) suspects a secret meeting between Bob 
and Alice, for this evening, and she want to enhance 
her suspect by discovering sensitive privacy settings 



of Bob in his favorite GeoSN. Mary tries to make 
a resource r = ("Alary, Bob, Alice" , "Today, 22 : 
30p.m." , S, C) that means: "Mary is co-located in C 
with Alice and Bob" . The GeoSN notify Mary that 
if she want to make this resource she have to set an 
area that guarantee more distance between users, be- 
cause she is violating the privacy of someone. With 
this information, Mary can exclude that she is violat- 
ing her privacy (she hasn't any privacy setting) and 
the privacy of any other user outside Alice and Bob, 
because there isn't any other resource that co-locate 
other users with Bob or Alice at the time she want 
to make the resource (She has a complete view on 
R). Thus, Mary can enhance her suspect of a secret 
meeting between Alice and Bob. 

This example shows why we introduced the 
Adversary Set in the privacy settings. If a user u 
knows who could be a potentially adversary, (s)he 
can put her/him in the Adversary Set. The effect 
is that any resource r that include a user in <p.A is 
allowed even if r violates the privacy preference ex- 
pressed by ip. 

Note that a sly adversary could exploit her/his in- 
clusion in the Adversary Set for a particular kind of 
attack. For instance, imagine that Mary (the jealous 
wife of Bob) suspects a secret meeting between Bob 
and Alice, and she also suspects her inclusion in the 
Adversary Set of Bob' privacy preferences. If ex- 
ist some resources that locate Bob somewhere, Mary 
could makes a fake resource that locate herself near 
Bob. Thus, any co-location of Bob with Alice (near 
Mary) is allowed and Mary can enhance her suspects 
if they occur. Although this kind of attack is possible, 
we believe that it's difficult to succesfully accomplish, 
due to the need of multiple necessary conditions for 
its achievement. Moreover, in contrast to the previ- 
ous attack, the pubblication of fake resources is re- 
quired, then the victims can easily became aware of 
this fact. 

2.4 Co-Location Privacy Preservation 

In this section, we identify a set of sufficient condi- 
tions that R must satisfy in order to guarantee the co- 
location privacy preservation. These conditions iden- 
tify a set of possible scenarios that must be avoided in 



order to have not null the probability of co-locating 
a user u with an Excluding set £ in a time interval 
T with a maximum distance greater than D. 

As mentioned before, the co-location can occur in 
two ways: a direct way and a indirect way. In the 
following we formalize these concepts. 

Definition 5 (Direct Co-Location). A Direct Co- 
Location of u considering p S &(u), is a resource r 

uer.U A r.UC\p.E^$ A r.U r\tp.A = <!) (10) 

and we indicate it with the syntax: r — » (u,(p). 

A direct co-location must be avoided if it reveals 
that u and any user in (p.E can't be co-located with 
a distance greater than ip.D in the time interval tp.T. 
This leads us to define the validity concept for a 
direct co-location. 

Definition 6 (Valid Direct Co-Location). A Valid 
Direct Co-Location of u considering <p> G $(u), is a 
resource r <G R: 

r -> (u, if) A r.T £ p.T A 
1 p.D (11) 

2' \r.T - n(ip.T)\ < Vmax 

where n(tp.T) compute the nearest t e p.T to r.T that 
is: tep.T: \r.T -t\< \r.T - t'\ W ^t£ tp.T. 

The last condition condition of fll| ) states that if a 
co-location occurs before or after tp.T (Fig. [2]), u and 
any users in ip.E have the possibility of being located 
with a distance greater than ip.D in the time inter- 
val p.T because they have enough time to leave each 
other, if they move with acceptable medium speed. 
In Fig. [2] we report the spatial information of a re- 
source as one-dimensional data. In a real context it 
would be a two-dimensional data, but this doesn't 
affect the semantics of our examples. 

Definition 7 (Indirect Co-Location). An Indirect 
Co-Location of u considering p> € <&{u), is a pair of 
resource (r, r') € R x R: 

r^r' A uer.U A r'.U^p.E =t$ A 
(r.U U r' '.£/) D (p.A = A 
ip.D - d(r.S - r'.S) 



Space 



(12) 



Space 



<P.T 



n(r.T) r.T 
w j time 



Figure 2: Direct Co-Location. 

where d(r.S,r'.S) compute the maximum distance be- 
tween the two location. We indicate it with the syn- 
tax: (r, r 1 ) — > [u, ip). 



The last condition of (12 1 states that the two re- 



sources are close in time. This permits us to con- 
sider the users involved in the co-location in an area 
smaller than p.D at the time max(r.T, r'.T). 

As a direct co-location, a indirect co-location must 
be avoided if it reveals that u and any user in p.E 
can't be co-located with a distance greater than ip.D 
in the time interval p.T. 

Definition 8 (Valid Indirect Co-Location). A Valid 
Lnirect Co-Location of u considering p £ &(u), is a 
pair of resource (r, r') € R x R: 

(r, r') -> (u, ip) A 
[min(r.T, r'.T), max(r.T, r .T)] n p.T /I A 

1 p.D - d(ext(S, \r.T - r'.T\),S') 

2 \max(r.T, r'.T) — n(max(r.T,r'.T))\ 



<V m 



(13) 

where S is the spatial information associated to 
the resource with temporal information equals to 
min(r.T,r' -T), and S' is the spatial information as- 
sociated to the resource with temporal information 
equals to max(r.T,r' .T). 



The second condition in ( 13 ) states that the time 



\r.T -r'.T\ 



>V„. 



of the co-location must not overlap with the time 
interval p.T. The last condition states that if the 
co-location occur before or after p.T (Fig. [3]), u and 
any users in p.E have the possibility (like in the di- 
rect co-location) of being located with more distance 



Space 
A 

r'.S . 

r.S . 



ext(r.S, t) 



r.T r'.T n(r'.T) 



P.T 



n(r.T) r.T r'.T 



■f.T 



Figure 3: Indirect Co-Location. 



than tp.D in the time interval tp.T. For example, the 
indirect co-location in Fig. [3] (a) is valid if at the time 
r'.T, dmax{r.r') < tp.D and the involved users can 
depart for at least tp.D within n(ip.T), moving with 
an acceptable medium speed. 

An important property of a valid co-location 
(direct or indirect) considering p, is that if we don't 
take into account any other resource, the informa- 
tions given by the co-location are not sufficient to 
determine that Ve <E ip.E the distance between u and 
e is not greater than ip.D in the time interval tp.T. 
This implies that: Vi G ip.T Ve € ip.E, P(d(u, e) > 
ip.D) > 0. 

In a set of dependent resources, a valid co-locaiton 
can still violate the privacy of a user u. For instance, 
let tp = ({e},0,T, D) be a a privacy preference for 
the user u. The Fig. [4] shows two valid indirect co- 
location of u considering tp. But if we consider the 
gray circle (the area reachable from r.S in the time 
interval t) we can infer that, at the time r'.T, u can 
be located only in the area with black stripes, and 
this violate the privacy of u. 

Note that the given example is not valid if we con- 
sider a set of independent resources. This lead us to 
define two sufficient condition that R must verify in 
order to preserve the co-location privacy, that are: 

(a) \t(r,r') e R x R, r _L r' 

(b) Vw Vp G P( u ) V C Co-Location (direct or 
indirect) of u considering p, C is valid. 

Whenever a resource r is added to R, it must be 
independent from any other resource in R and it must 
not generate any invalid co-locations. If an invalid 
co-location occurs, we apply a generalization function 




r'T > r.T 

r'T - r.T = t 
u in r.U 
u in r'.U 
e in r".U 



Figure 4: Privacy violation in a set of dependent re- 
sources. 



g defined in section 2.1 



3 Co-Location Privacy Preser- 
vation Algorithm 

In this section we propose a sequential algorithm for 
preserve the co-location privacy in a GeoSN mod- 
eled as described in the previous sections. This algo- 
rithm takes in input a set of independent resources 
R that preserve the co-location privacy (the GeoSN 
resources) and a resource r, and it tries to add r to 
R ensuring that the new set of resources preserve the 
co-location privacy as well. The algorithm is based 



on the conditions (a), (b) given in the section 2.4 



Note that in the section 12721 we state that the set 
of privacy settings for a user u can be infinite. This 
problem can be easily avoided by extending the defi- 
nition of a privacy preference tuple, for example by 
adding a frequency flag that could assume a value 
among: "every day", "every week", "every year". 

Before the execution of the co-location privacy 
preservation algorithm, r is pre-processed to make 
it independent from any other resource in R. This 
topic is widely discussed in [2J, in the "WYSE Tech- 
nique" section. In particular [2] proposes two dif- 
ferent algorithms, called CountryCloakWyse and 



ClockWyse that apply a generalization on the spa- 
tial or temporal dimensions, respectively. Since in 
this paper, we use a real-time publication model, 
only the CountryCloakWyse algorithm is suitable 
for our purpose. 

Algorithm 1 Co-Location Privacy Preservation Al- 
gorithm (1) 
Require: R set of independent resources, 

r resource : RL){r} set of independent resources 
Ensure: r not invalid direct co — location 
for all u E r.U do 
for all ip £ $(u) do 

if -^isV alidCoLocir, u, ip) then 

r.U i-r.U\<p.E 
end if 
end for 
end for 

After a resource is guaranteed to be independent 
from every other existing resource, the co-location 
privacy preservation algorithm is executed. This al- 
gorithm is composed by two different parts. The first 
part (Alg. fTl) is responsible for modifying r if an 
invalid direct co-location occurs. In this case, only 
users erasure is applicable. 

Instead the second part (Alg. [2| is responsible 
for avoiding invalid indirect co-locations. The first 
step of Alg. [2] is the computation of the Co-Location 
Graph that is a data structure used to support the 
indirect co-location identification. It is defined as fol- 
lows: 

Definition 9 (Co-Location Graph). A Co-Location 
Graph is a not direct graph G=(V, E) : 

• V is the set of vertices and represents a set of 
resources. 

• E C V X V* is the set of edges that link near 
resources. The edges are enriched with a distance 
information d (maximum distance between two 
vertices). 

A co-location graph connects any two resources if 
they are geo-located with a small distance. The co- 
location graph building, in the Alg. [2] starts consider- 
ing the resource r, and W G R : d(r.S, r' .S) < D max , 



the building process creates an edge between r and r' 
enriched with d(r.S, r'.S). At the end of the process, 
the data structure G is similar to the graph showed 
in Fig. [5] 



Algorithm 2 Co-Location Privacy Preservation Al- 
gorithm (2) 
Require: R set of independent resources, 

r resource : RU {r} set of independent resources 
Ensure: VV G R, (r, r') not invalid indirect co — 
location. 

committed <— false 
G <— buildC oLocationGraph{r) 
for all (r, r') e G.E do 

for all u <E r.U U r'.U do 
for all ip € $(u) do 

if -^isValidCoLoc((r,r'),u,ip) then 
S' <— enlargement (r.S 7 r' .S,<p.D) 
if 5" y^ null then 
r.S <-r.S + S' 
else 

if (r.U\u\tp.E) 3 owner (r) then 

r.U <r- (r.U\u\p.E) 
else 

Deny r. return 
end if 
end if 
end if 
end for 
end for 
end for 
sync 

G' <— buildC oLocationGraph(r) 
if G = G' then 
R<r- RU{r} 
committed <— true 
end if 
end sync 



After the co-location graph building is done, the 
algorithm iterates for all possible invalid indirect 
co-locations and avoids them by obfuscating the 
geographical meta-data given by r. The function 
enlargement(r.S,r' .S,p.D) computes an area S' : 



3(s, tf) € {r.S + S') x r'.S : d(s, s') = <p.D A 
Vr" e R, r" _L (r.U, r.T, r.S + S',r.C) 



(14) 



If such an area can't be computed, the algorithm 
applies a users erasure. If also users erasure can't 
also be performed, the resource r is denied. At the 
end of the Alg. pi), if there aren't new involved re- 
sources in the co-location graph G, the resource r is 
atomically committed to the whole resources set R, 
otherwise (committed — false) the algorithm must 
be re executed. Atomicity is required because multi- 
ple instance of the Alg. pi) can run at the same time 
due to multiple resource publication from different 
users at the same time. 

After the Alg. ([I]) and ^ are executed, the user 
is notified about the changes made on r before the 
pubblication. 




can generalize it to a coarser one (such as a neigh- 
borhood or city). In contrast, a tweet's utility gen- 
erally relies heavily on its publication in real time. 
Other services require using an exact location, but 
resources doesn't need to be published instantly. In 
this case the proposed technique must be extended in 
order to apply a temporal cloaking instead of a spatial 
cloaking. Finally, for services that require both high 
spatial and temporal accuracy, applying any spatio- 
temporal cloaking techniques wouldn't be possible. 
For these services, we can obfuscate the set of users 
involved in resources by the erasure of some of them. 
Encryption is also a potentially effective solution. 

In the case of a GeoSN allows to omit the geotag, 
the co-location privacy preservation is more difficult 
due to an additional kind of attack that the adversary 
could perform to infer the geo-location of a user. For 
instance, the adversary may infer the location of a 
user u, if exists a resource r that co-locates u with 
another user u' without geographical information and 
another resource r' (with a small temporal difference 
from r) locates u' in a certain place. 

In [7] an overview of the features of existing 
GeoSNs is given. We can observe that our technique 
is suitable for services like: Twitter, Google Latitude, 
Google Buzz, Grindr and Loopt. 



5 Conclusion 



Figure 5: Co-Location Graph. 

4 Applicability to Existing 
GeoSNs 

In some GeoSNs, the temporal or the spatial di- 
mension is less crucial and thus it can be general- 
ized if a privacy concern exists. If the resources of 
a GeoSN doesn't require exact location but require 
real-time publishing, the technique presented in this 
paper could be applied in order to preserve the co- 
location privacy. For instance, Twitter doesn't re- 
quire that users publish an exact location and they 



Since social networking services continue to prolifer- 
ate, there is an increasing need of preserving users 
privacy. This paper addresses a particular privacy 
threat that is the co-location privacy. We propose 
a way for expressing privacy settings of users and a 
study of how they can be preserved in the context of 
"real-time publishing" GeoSNs. The paper formal- 
izes the setting, provides a way for easily defining 
privacy preferences, and provides a technique that 
generalizes the tags of resources so that these remain 
useful while ensuring that the privacy preferences are 
preserved. This technique exploit spatial general- 
ization or users erasure (where the first one is not 
possible). In this paper we take into account only 
meta-data of resources to preserve users privacy, but 
the content of a resource itself could raises privacy 



threats. For example a photo can co-locates some 
users against their will. Future research can be done 
in this direction to face this problem. Moreover, the 
proposed technique can be extended in order to face 
the co-location privacy threat in GeoSNs that don't 
require real-time publishing. In this case, temporal 
cloaking of resources is also possible. 
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